1. Technical Field
The present invention relates in general to a system and method for supporting run-as credentials delegation using identity assertion. More particularly, the present invention relates to a system and method for storing a user identifier without a corresponding password on a server, inserting the user identifier in an identity assertion token, and using a run-as command to send the identity assertion token to a downstream server.
2. Description of the Related Art
Businesses are increasingly dependent upon using computer systems for business activities. A computer system compromise in terms of information loss, information inaccuracy, or an information security breach may be costly to a business. Security breaches are becoming more frequent and may be due to accidental misuse of a computer system, such as a user accidentally gaining unauthorized access to information. However, security breaches may also be due to malicious attacks by computer hackers to gain access to sensitive information.
Distributed computer systems are more vulnerable to security breaches than more traditional computer systems since distributed computer systems include more areas from which the computer system may be attacked. Computer security systems typically focus on four main areas to protect a computer system from unauthorized access attempts. These four areas are confidentiality, integrity, accountability, and availability. Confidentiality ensures that information is disclosed only to authorized users. Integrity ensures that only authorized users are able to modify information using authorized ways. Accountability ensures that users are accountable for their security-relevant actions, such as non-repudiation. Availability ensures that users may not be maliciously denied access.
Object Management Group (OMG) is an organization that establishes industry guidelines and object management specifications to provide a common framework for application development. OMG has developed specifications that particularly focus on network security. One such specification is the Common Security Interoperability version 2 (CSIv2) document which defines various levels of security architectures between computer systems. A developer follows CSIv2 security architecture definitions in order to ensure interoperability with other computer systems.
The CSIv2 document includes a definition for a security protocol called Security Attribute Service (SAS). The SAS protocol specifies how to exchange protocol elements that are communicated over a connection-based transport. The SAS protocol is intended to be used in environments where transport layer security is used to provide message protection (i.e. integrity and/or confidentiality) and server-to-client authentication. The SAS protocol provides client authentication, delegation, and privilege functionality that may be applied to overcome corresponding deficiencies in an underlying transport. For example, a SSL/TLS protocol does not enforce client authentication and, in a given environment, certificate-based client authentication may not be feasible since clients often do not have a certificate. The SAS protocol facilitates interoperability by serving as a higher-level protocol under which secure transports may be unified.
In a Java-based application, enterprise Java beans (EJB's) use the SAS protocol to communicate with other EJB's. EJB 2.0 is a document that specifies EJB characteristics and requires a server to propagate a security identity of either a requesting client or another specified identity to a downstream server. EJB 2.0 specifies a run-as command which allows a server to send a downstream request using a client's identity, a server's identity, or a specific pre-defined identity (see EJB 2.0 for further details).
For example, a developer may define a bean with several privileged administrative tasks (i.e. administrative bean). The developer may then define two different beans (i.e. interface beans) that make use of the administrative bean. The two interface beans may be assigned different run-as identities with varying degrees of access, enabling reuse of the administrative bean without compromising the secure access to its secure functions. A challenge found is that the propagating server stores a user identifier and its corresponding password in order to support EJB 2.0. Storing the identifier and password poses security issues.
Servlet 2.3 is a document that specifies servlet characteristics. Servlet 2.3 requires that a server propagate a security identity of either a requesting client or another specified identity to a downstream server when a servlet is invoking an EJB in the downstream server. A challenge found is that the propagating server stores a user identifier and its corresponding password in order to support Servlet 2.3. Again, storing the identifier and the password poses a security issue.
What is needed, therefore, is a way to support security protocol standards without storing a client's password on a sending server.